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ABSTRACT 

The  discipline  of  Software  Engineering  cm  be  extended  In 
n  neeurnl  way  to  deal  milk  the  issues  rated  by  a  systematic 
approach  to  the  design  of  heanan-machine  interfaces.  Two  main 
point  are  made:  thm  the  oxer  should  be  treated  at  port  ef  the 
system  being  designed,  and  that  projects  should  bt  organised  to 
take  mcount  of  the  current  (small)  stme  of  a  priori  knowledge 
about  haw  to  design  interfaces. 

Becmise  the  principles  ef  good  user -imerf  ace  design  are 
not  yet  well  specified  (rnd  not  yet  known),  interfaces  should  bt 
developed  through  an  iterative  process.  This  means  that  it  is 
tssential  to  develop  tools  for  evaluation  and  debugging  ef  the 
imerf  act,  much  tht  same  way  as  tools  hart  been  developed  for 
tht  evaluation  and  debugging  of  progrmn  code.  We  need  to 
develop  methods  of  detecting  bugs  in  the  imerf  act  and  of  diag¬ 
nosing  their  cause.  The  tools  for  testing  imerf  acts  should 
include  measures  of  imerf  act  performance,  acceptance  tests, 
and  benchmarks.  Developing  useful  measures  is  a  nan-trivial 
task,  but  a  stmt  cm  and  should  be  made. 


Introductiea 

The  subject  of  this  paper  is  tbe  extension  of  Software 
Engineering  to  deal  witb  tbe  issues  raised  by  tbe  design  of 
human-machine  interfaces.  To  a  large  extent,  all  that  is 
needed  is  to  take  the  problem  of  engineering  tbe  user  inter¬ 
face  as  seriously  as  any  other  part  of  software  engineering 
and  to  apply  to  it  tbe  same  kind  of  techniques,  appropri¬ 
ately  adapted.  For  instance,  although  the  interface  is  imple¬ 
mented  in  software ,  it  can  be  thought  of  as  being  *mn*  on 
human  users.  This  means  that  we  must  modify  our  concept 
of  a  program  bug  to  allow  for  part  of  tbe  system  to  be  a  per¬ 
son;  we  must  establish  new  performance  criteria  for  tbe 
combined  human-plus-interface  system.  Much  of  tbe  thrust 
of  this  paper  is  simply  to  draw  analogies  with  existing 
software  practices  in  order  to  suggest  how  to  support  a  pro- 

♦This  mutch  mm  tondaetad  aadar  Cost  net  N00014-79C-C82J,  NR 
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faniona!  approach  to  interface  design.  We  do  not  present 
detsiled  ideas  on  whtt  interfaces  should  be  like,**  but 
rather  sketch  some  consequences  for  software  engineering 
when  interface  design  is  taken  seriously. 

Them  are  two  themes  in  this  paper:  arguing  by  anal¬ 
ogy  with  existing  practices  to  their  extension  to  interface 
design;  mid  arguing  from  tbe  nature  of  the  problems  of 
interface  desip  to  requirements  for  an  appropriate 
engineering  discipline.  Tbe  first  part  of  the  paper  makes 
tome  general  points,  tbe  second  summarizes  their  conse¬ 
quences  for  tbe  coding,  documentation,  debugging,  and 
testing  phases. 

Software  Engineering  for 
Hnmaa-Compnter  Interface  Design 

Two  Goals  in  Optimizing  an  Imerf  ace 

We  begin  witb  a  tradeoff  that  has  clear  parallels  to 
aspects  of  software  engineering,  the  tradeoff  between  two 
quite  different  broad  aims  for  an  interface: 

•  Achieving  speed  and  convenience  of  use  (power )  for 
the  practiced  user; 

•  Achieving  ease  of  learning  and  use  ( ELV ). 

These  distinctions  are  related  to  tbe  familiar  novice-expert 
distinction.  Thera  is  a  clear  analogy  between  these  aims  and 
the  desire  to  optimixe  space  and  time  in  software  perfor¬ 
mance.  In  general  it  is  desirable  to  optimize  both  aims,  but 
beyond  a  certain  point,  the  engineer  must  choose  a  particu¬ 
lar  tradeoff  between  the  two.  This  analogy  bolds  quite 
closely.  Not  only  Is  there  s  reasonable  region  where  one  aim 
trades  off  against  tbe  other,  but,  at  the  extremes,  tbe  pro¬ 
grams  can  be  generally  unusable. 

'*  w*  la***  Ml  ef  tklt  papas  way  major  dlacaaaioa  of  what  a  haasae- 
eompatar  tatarfac*  oa|kl  to  b*.  or  what  tk*  (astral  problem  or 
priodptm  art.  became  tklt  topic  la  attend  I*  eamaroaa  other 
papan  by  *>  aad  by  tb*  powtai  cemmoaity  of  people  who  work  <a 
tb*  Md  called  It  mem  C mower  huerettlem.  Thu  (aid  oow  baa  a 
aaaoal  amstag.  ament  feanat*.  aad  a*  ACM  Special  lateral  Oroap 
(SIQCHI):  w*  ate  oe  lead  to  cover  tb*  material  here.  Sat.  for  exam- 
plc,  l ha  Preteedinee  ef  tb*  OB  O  Cmfereeee  m  Hwem  Farters  im 
CememWt  Systems'  Tbit  pap or  cooccairatee  ot  tbe  leaaoat  that  caa 
bo  applied  to  ittarfm  dcaiga  from  practices  already  comma  la 
Software  gigluonng. 
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Coerider  tke  extremes.  Suppose  we  optimized  pis- 
gram  speed  or  iaterface  power.  Just  is  t  fast  pro  pram  that 
requires  more  space  than  eay  customer  cao  afford  la  ia  prac¬ 
tice  use  teas,  so  too  is  ao  iaterface  that  provides  immensely 
fast  sad  'powerful*  iateractioa,  but  at  the  east  of  (equities 
such  a  level  of  skill  that  ao  user  will  actually  be  able  to  use 
it  because  of  the  difficulty  of  learaias  it  presaats.  Similarly, 
if  we  optimized  program  space  or  ELU,  the  profrsta  might 
be  too  slow  to  use  regularly  (ao  matter  how  escaoarical  of 
space)  aad  the  interface  caa  be  too  laborious  for  a  regular 
user  to  employ  productively,  ao  matter  how  safe,  ‘friendly,* 
helpful,  and  easy  to  lean.  If  we  avoid  the  eatremes  of  these 
dimensions,  then  there  b  a  wide  range  of  cboies  for  the 
designer.  The  existence  of  programs  of  similar  function  on 
microprocessors  and  large  mainframe  computers  is  a  strong 
reminder  that  we  can  tradeoff  both  ia  the  spaeo-tiaM 
domain  for  the  software  aad  in  the  power /ELU  domain  for 
the  user  interface. 

User  mid  Program  as  Commmicatitig  Codtoiaines 

When  a  programmer  implements  a  system  with  a  user 
iaterface,  he  or  she  is  not  only  defining  what  the  machine 
will  do  but  also  defining  what  the  user  caa  do.  the  pro¬ 
gram  aad  user  caa  be  thought  of  as  co-rouciaas,  each  com¬ 
municating  with  one  another.  The  programmer  most  expli¬ 
citly  or  implicitly  decide  what  actions  aad  information  will 
be  available  to  the  user.  For  any  given  interface,  this  point 
can  be  illustrated  by  drawing  a  flow  chart  of  the  user's  part 
of  the  process.  Although  this  point  teems  simple,  it 
changes  the  fundamental  (though  usually  unacknowledged) 
situation  by  which  programming  takes  place.  No  longer  are 
programmers  engaged  in  the  private  task  of  getting  the 
machine  to  do  something  for  themselves  they  me  am  even 
engaged  in  communicating  a  program  to  other  programmers, 
a  view  intermittently  voiced  by  purist  pm  gram  men. 
Instead,  the  interface  designer  should  be  viewed  as  someone 
who  must  write  a  successful  co-routine  between  user  aad 
machine,  yet  where  the  full  specification  of  the  near  side  of 
the  co-routine  is  not  well  koowa  (and  may  be  variable): 
this  is  the  real  subject  of  the  design,  aad  this  mast  become 
the  conscious  objective. 

There  are  two  consequences  to  this  point,  both  dis¬ 
cussed  in  greater  detail  later  in  the  paper.  First,  we  need 
languages  that  support  this  view,  that  is,  that  represent  this 
co-routine  directly.  Second,  the  iateractioa  aaeds  tasting 
aad  debugging  on  typical  “hardware, '  hardware  that  indudea 
representative  users. 

The  State  of  User  Interface  Design 

How  much  is  known  about  hew  to  design  interfaces? 
We  must  answer  this  question  ia  order  to  pica  a  sensible 
software  engineering  strategy.  If  snou0  is  known  to  lay 
down  detailed  principles,  tbea  a  top-down  strategy  aright  be 
followed;  otherwise  an  iterative  strategy  mast  be  adopted 
with  emphasis  on  the  testing  aad  debugging  phases. 


Qumuitmive  principles.  Top-down  principles  of 
design  should,  ia  tbe  ideal  case,  allow  a  design  to  be  worked 
out  ia  advance  rather  than  entirely  by  trial  and  error  These 
tools  need  to  be  developed  from  a  solid  basis  in  experimen¬ 
tal  psychology,  coupled  with  a  good  understanding  of  pro- 
gramariag  aad  software  design.  Not  surprisingly,  the 
nuasber  of  groups  capable  of  this  work  is  limited  and  not 
much  yet  exists.  There  arc  now  several  initiatives  whose 
goal  Is  to  provide  quantitative  principles  for  tbe  design  of 
kutnaa -computer  interfaces.  For  example,  one  of  us  has 
shows  bow  it  it  possible  to  develop  a  quantitative  assess¬ 
ment  of  how  design  tradeoffs  affect  the  User  Satisfaction  for 
an  interface2.  Thus,  in  trading  of  time,  information,  and 
workspace,  it  is  possible  to  compute  tbe  tradeoff  space, 
showing  the  psychological  impact  of  tradeoffs  in  these  vari¬ 
ables.  A  complementary  approach  is  that  of  Card,  Moran, 
aad  Newell1  who  provide  a  set  of  quantitative  tools  for 
computing  the  operational  parameters  of  interfaces. 

The  development  of  psychologically  based,  quantita¬ 
tive  design  tools  is  still  ia  its  infancy  aad  much  work 
nmrini  to  be  doaa,  both  ia  development  aad  in  validation. 
If  we  caa  develop  sufficient  range  aad  breadth  of  quantita¬ 
tive  design  tools,  thaa  we  can  look  forward  to  a  time  when 
it  will  be  possible  to  provide  gsnrral  principles  and  even 
tables  of  numerical  values  ia  design  handbooks,  allowing 
such  design  considerations  as  workspace  size,  display  time, 
menu  structure,  comauad  language  design,  pointing-vetius- 
namiag,  interface  power,  and  ELU  to  be  amassed  at  the 
design  Stags,  without  the  aaad  to  build  a  test  system.  For 
the  piuseat,  however,  the  designer,  by  and  targe,  does  not 
have  quantitative  data  at  hand. 

QmdUmive  principles.  Ia  the  absence  of  well- 
sstabUshed  quantitative  design  rids,  we  need  methods  that 
allow  us  to  work  with  qualitative  principles.  A  large 
number  of  qualitative  principles  exist,  many  ia  the  form  of 
‘slogans, *  exhorting  tbe  designer  to  consider  this  factor  or 
that,  or  to  avoid  this  failing  or  that  UA'.  These  qualitative 
tules  are  often  quite  reason  able  (which  makes  it  especially 
discouraging  to  see  bow  frequently  even  the  most  obvious 
sod  elementary  principles  ate  violated  ia  existing  systems), 
rithou0  if  the  design  of  a  user  iaterface  is  ever  to  proceed 
ia  a  system utic  fashion,  we  need  to  go  beyond  this  level. 

Oae  major  example  of  tbe  attempt  to  base  a  system 
design  oa  fuadameatal  design  principles,  built  in  such  a  way 
as  to  capitalize  oa  the  user’s  existing  knowledge  is  the 
fieri ga  of  the  Xerox  Star  system*.  This  design  attempted  a 
systematic  strategy  based  oa  p  tin  dp  let  of  good  human- 
computer  iateractioa.  Since  then,  of  course,  other  systems 
have  beea  developed  along  similar  principles  (in  particular, 
the  Apple  Use  system).  Tbe  Star  illustrates  tbe  delicate 
tradeoff  dacirioat  that  mutt  be  faced:  tbe  attempt  to 
optiarise  ELU  led  to  degradation  of  performance,  especially 
ia  speed  of  the  system,  as  welt  as  to  a  high  selling-price. 
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Specif  {cations  f  or  inter facts 

la  defining  and  addressing  a  software  project  two 
questions  must  be  tackled:  wbat  kind  of  specifications  are 
reasonable  for  defining  the  project?,  wbat  kind  of  divisions 
of  the  project  into  subtasks  are  likely  to  be  viable?  The 
tame  observation  applies  to  both:  specifications  are  deter* 
mined  et  an  early  stage  and  mutt  remain  constant  if  massive 
re-writing  is  to  be  avoided. 

Sbeil*  argues  against  the  utility  of  a  Structured  Pro¬ 
gramming  approach  to  user  interface  desip.  Sbeii  points 
out  that  whatever  the  virtues  of  that  approach,  it  depends 
on  having  a  clear  and  fixed  specification  at  the  start.  The 
technique  becomes  strained  whenever  the  specifications 
change  during  the  life  of  the  software.  Although  in  the 
ideal  cate  a  Structured  Program  practitioner  would  re-do 
the  whole  desip  and  implementation  at  every  change  in 
specification,  in  practice  the  investment  in  the  easting  code 
and  desip  exerts  an  enormous  pressure  toward  piecemeal 
ebanp.  i.e.,  toward  iterative  redetip.  In  areas  where  such 
shifts  in  specification  are  common,  it  seems  better  to  face 
the  fact  that  development  will  in  practice  be  iterative.  Sheil 
suggests— and  we  agree— that  interface  desip  is  one  such 
area. 

Several  consequences  follow  from  this  point  of  view. 
First,  it  will  be  uawise  to  allow  any  details  of  a  user  inter¬ 
face  to  appear  in  the  project  specifications:  for  instance 
instead  of  giving  a  list  of  the  commands  to  be  implemented, 
specifications  should  rather  be  of  the  form  discussed  by 
Sbneiderman10,  who  suggests  instituting  acceptance  tests 
for  interfaces  such  as  'after  7S  min.  of  training  40  typical 
users  should  be  able  to  accomplish  80%  of  the  benchmark 
tasks  in  35  min.  with  fewer  than  12  errors*  A  professional 
approach  to  user  interface  desip  puts  the  responsibility 
with  the  desiper,  having  the  user  or  customer  specify  per¬ 
formance  requirements  rather  than  details,  just  as  in 
Sbneiderman 's  hypothetical  acceptance  test.  This  leaves  the 
desip  of  the  interface  to  the  software  team,  but  with  expli¬ 
cit  standards  for  the  specification  of  the  performance  of  the 
system. 

A  second  consequence  is  that  we  must  expect  to  have 
to  p  tbroup  many  iterations  on  details  of  the  interface.  If 
the  overall  project  it  to  be  subdivided  by  dividing  the  sys¬ 
tem  into  modules  that  are  separately  desiped  and  imple¬ 
mented,  then  a  third  consequence  is  that  the  user  interface 
should  be  segrepted  into  a  single  module  which  all  other 
modules  mutt  use  if  they  communicate  with  the  end  user. 

Separating  interface  design  from  program  design. 
This  strategy  consists  of  isolating  the  main  program  in  one 
set  of  modules,  the  user  interface  in  another,  and  consider¬ 
ing  the  user  as  comprising  a  third: 

Interfaea  Program 

User  <•■•>  <  ■■•> 

Module  Modules 

The  virtue  of  this  view  is  well  known  la  the  software 


engineering  community:  at  long  as  the  communication 
structure  and  the  data  representation  are  well  specified  and 
adhered  to,  the  modules  can  be  worked  on  independently 
and  changed  at  will,  without  any  effect  on  the  rest  of  the 
system.  The  communication  between  the  Interface  and  the 
User  can  be  changed  in  any  arbitrary  manner  as  long  as  the 
communication  between  the  Progran  and  the  Interface  it 
not  affected.  This  requires,  of  course,  that  the  only  part  of 
the  system  that  may  interact  directly  with  the  user  it  the 
Interface  Module.  A  well-defined  protocol  between  the 
main  program  and  the  interface  module  can  be  defined  at 
the  outset,  leaving  the  interface  desiper  free  to  chanp  the 
interface  without  interfering  with  the  independent  develop¬ 
ment  of  the  main  program.  An  important  benefit  of  this 
modularization  strategy  it  that  it  allows  separate  specialists 
to  work  on  the  main  program  and  on  the  interface  module. 

A  good  example  of  this  modularization  combined  with 
support  for  a  heavily  iterative  approach  to  developing  the 
user  interface  is  provided  by  the  database  and  interface 
pack  apt  TroWUSE  (the  database)11  and  RAPIDiUSE  (the 
interface  package)12  TroWUSE  is  a  relational  database~the 
'main  program*  module.  RAPIDiUSE  is  a  toot  for  the 
deeip  of  interactive  dialopes  and  systems,  allowing  for 
rapid  modification  and  experimentation  of  the  interface 
(through  a  transition  network  specification),  yet  maintain¬ 
ing  constant  the  necessary  communication  protocol  to  the 
database,  TralUUSE.  ■  Clearly  the  desip  of  a  database 
requires  different  skills  than  desiping  a  user  dialogue,  and 
in  fact  RAPIDiUSE  is  desiped  to  allow  non-programmers  to 
desip  the  dialope  using  a  simple  interpreted  language 
Other  examples  are  the  DMS  system11  and  the  work  by  Bux¬ 
ton  et  al.14 

Makeup  of  interface  design  teams.  A  further  conse¬ 
quence  of  the  special  nature  of  interface  desip  affects  the 
organization  of  the  desip  team.  If  the  principles  of  inter¬ 
face  desip  were  developed  to  the  point  where  their  applica¬ 
tion  required  no  personal  expertise,  and  if  the  tradeoffs 
were  all  identified  and  quantified  in  advance,  then  a  split 
between  groups  of  experts  might  be  workable.  It  is  notice¬ 
able  that  some  of  the  more  successful  interface  desips  (e.g., 
the  Xerox  Star  and  the  Apple  Use)  have  been  done  by 
teams  which  included  people  with  diverse  talents  and 
training,  but  which  did  not  make  a  distinction  between 
evaluators  and  implementors,  between  psychologists  and 
programmers.  We  interpret  this  to  indicate  that  at  the 
present  time  the  closest  cooperation  is  required  to  identify 
and  resolve  tbe  unexpected  tradeoffs  that  surface  in  the 
course  of  a  desip.  Many  desip  questions  are  at  heart 
unfoneen  tradeoff  decisions,  and  these  can  only  be  reason¬ 
ably  made  by  people  who  appreciate  all  tbe  factors  involved. 
This,  althoup  a  separation  of  tbe  interface  from  other  pro¬ 
gram  modules  is  highly  beneficial,  and  althoup  logically  tbe 
skills  required  for  desiping  each  are  quite  different  (e.g., 
dialope  desip  versus  application  programming),  it  seems 
that  tbe  unknowns  in  interface  desip  continue  to  demand 
dose  cooperation  between  parts  of  desip  teams. 


3 


Drtpsr  ft  Nomas 


Influences  of  the  Interface  oa  Code 

Languages  for  User  Interface  Design 

We  have  argued  that  interface  designers  need  to  be 
aware  that  they  are  designing  a  dialogue,  and  more  than  that 
a  co-routine,  between  user  and  computer.  The  idea  immedi¬ 
ately  follows  that  special  languages  that  represent  this  view 
woutd  be  an  important  aid.  Certainly  conditional 
languages  are  poor  in  this  respect  because  they  are  machine- 
centered:  they  describe  events  around  the  sequence  of 
machine  actions  with  input  and  output  seen  is  side-effects 
W merman's  RAPIDWSE  system  offers  the  designer  a 
language  based  on  Transition  Diagrams,  where  nodes 
correspond  to  a  machine  state  and  the  output  displayed  at 
that  point,  and  the  various  arcs  from  a  node  correspond  to 
alternative  user  inputs.  This  is  a  major  step  in  the  right 
direction.  It  is  perhaps  not  a  complete  solution  because  it 
is  essentially  a  representation  of  the  machine  the  user  sees 
(as  a  quasi-finite  state  machine)  rather  than  of  the  co¬ 
routine.  The  user’s  processes  are  only  implicit  (though 
much  easier  to  see  than  in  ordinary  languages),  and  machine 
actions  ate  represented  only  as  side-effects  of  transitions. 
Until  further  advances  in  this  area  are  made,  exercises  such 
a*  flow-charting  the  user's  decision-making  and  actions  will 
remain  important. 

The  Interface  to  the  User  Module 

We  have  argued  that  the  user  should  be  viewed  as  a 
module  of  the  system.  Good  'programming  practices  now 
demand  that  one  cstabfisfa  a  uniform  communication  proto¬ 
col  early  in  the  design  phase  and  stick  to  it.  Part  of  the 
rationale  is  economy— if  module  U  bat  to  use  one  protocol 
for  interacting  with  module  A  and  another  for  module  B,  it 
will  take  more  code  to  do  so.  (Or.  by  analogy,  if  you  think 
of  module  (J  as  being  the  User,  then  the  user  has  more  to 
learn.)  In  addition,  there  is  scope  for  confusion  and  error 
in  the  programming  if  there  is  not  a  uniform  protocol  (in 
the  analogy,  the  lack  of  consistency  makes  it  harder  for  the 
user  to  learn  and  to  apply  the  protocols). 

Theta  arguments  apply  be*  to  low-level  user  proto¬ 
cols.  The  more  programs  use  a  given  protocol  for  interac¬ 
tion,  the  more  benefit  the  user  pins  from  the  associated  set 
of  skills  in  using  it  (i.e.,  from  their  associated  ‘'subrou¬ 
tines’).  Thus  a  user  is  helped  if  all  parts  of  the  system  use  a 
small  number  of  common  protocols  for  interaction,  proto¬ 
cols  that  the  designer  can  think  of  as  corresponding  to  sub¬ 
routines  in  the  user's  mind/ 

ft  is  not  sufficient  to  think  of  the  user  as  a  simple  sys¬ 
tem  module  with  a  single  protocol  for  interacting  with 
other  modules.  There  are  many  layers  of  protocol,  just  as 

t  A  ataior  problem  here  is  to  ensvre  a  match  bclwaaa  tin  actions 
expected  of  the  mar  and  the  capabilities  of  that  oast.  This  is  one  of 
the  major  themes  of  research  oa  btsmaa -computet  latarastloi.  tad  is 
a  aos-trmai  problem,  fa  feast*!.  w*  would  submit  that  here  is 
where  the  software  assignee  must  interact  with  a  human-factors  or 
psychology  software  designer  —  during  the  design  phase  —  to 
derelap  the  specifications  of  the  user  actions. 


there  are  in  computer  networking.  At  least  three  levels  may 
be  distinguished:  (1)  the  low-level  protocols  just  discussed; 
(2)  the  conceptual  model  of  the  domain  t he  designer  wishes 
to  present  to  the  user;  and  (3)  the  highest  level  where  the 
user  has  several  concurrent  goals  (e.g.,  to  send  a  letter  or  get 
a  budget  analysis)  and  tbe  computer  is  one  means  to  the 
ends.  Most  of  our  knowledge  about  human-computer 
interaction  is  at  tbe  first  two  levels:  little  it 
underttood/known  about  the  highest  level  of  user  goals 
The  Xerox  Star,  the  Apple  Lisa  and  Viticele  can  be  teen  as 
paradigm  examples  of  the  second  level  in  that  the  system 
image  was  decided  early  os  as  a  major  design  decision  which 
defined  the  context  in  which  the  rest  of  the  interface  was 
developed. 

Standardised  Packages 

A  major  development  toot  would  be  the  creation  of 
various  packages  for  doing  standard  interface  operations 
There  are  two  separate  motivations  for  this: 

•  To  provide  a  language  at  tbe  right  level  for  tbe 
designer  (where  the  operations  are  elements  of  user 
interaction  and  lower-level  details  can  be  bidden); 

•  To  provide  standard  modes  of  interaction  across 
the  system  to  help  the  user. 

The  first  provision  helps  the  designer  to  work  on  tbe  design 
of  the  Interface  undittractcd  by  implementation  details. 
The  second  provision  gives  s  standsrdixstion  (consistency) 
across  applications  that  helps  the  user,  as  argued  above. 
Simply  providing  packages  is  often  enough  to  get 
sttndaidization— if  makes  it  easier  for  a  programmer  to  con- 
fortn  than  to  dissent.  There  is  great  need  for  software  tools 
for  interfaces,  including  screen  management,  user-program 
dialogue,  and  packages  for  doing  help,  argument  parting, 
history,  and  undo.  A  good  example  it  Perlman's1’  general 
interface  package. 

Documentation  an  an  Integral  Part  of  the  Interface 

As  obvious  consequence  of  integrating  user  interface 
design  into  tbe  overall  software  engineering  is  to  integrate 
documentation  and  code  generation.  Mashey  and  his  col¬ 
leagues  st  Bell  Labs  have  taken  a  major  step  in  this  direction 
by  using  the  tame  file  control  system  for  both  source  code 
and  documentation’*,  thus  promoting  their  simultaneous 
development  and  allowing  immediate  checks  on  whether 
one  it  out  of  date  relative  to  the  other.  Knuth’s  recent 
work  is  along  tbe  same  lines’7.  This  it  most  likely  to  benefit 
other  programmers  (rather  than  users)  who  will  have  to 
maintaia  tbe  code,  since  they  are  often  tbe  major  benefi¬ 
ciaries  of  complete  and  correct  documentation.  However,  if 
it  is  true  that  no  interface  design  is  likely  to  remain  fixed 
for  long,  then  It  it  not  enough  for  it  to  be  friendly  to  tbe 
user — it  must  be  friendly  to  its  msintsiners  as  well. 

The  term  ’documentation’  should  not  be  viewed  too 
narrowly.  Users  get  information  from  a  number  of  sources 
including  manuals,  tutorials,  error  messages,  and  norma) 


displays.  One  tot  of  tbe  adequacy  of  the  overall  documen¬ 
tation  it  to  introduce  an  error  in  the  operation  of  the  sys¬ 
tem  while  observing  a  'typical*  user  in  a  'typical'  situation. 
The  observation  of  interest  is  to  determine  how  the  user 
copes  with  the  situation:  the  design  fail*  the  test  if  the  user 
cannot  recover  gracefully.  It  is  important  to  note  how  the 
user  determines  the  state  of  the  system  and  the  options  that 
ate  available,  and  also  to  observe  what  the  user  actually  does 
(which  may  be  quite  different  from  what  the  designer  had 
in  mind). 

The  success  of  the  system  will  usually  depend  on  a 
combination  of  information  sources  and  is  neither  a  pro¬ 
perty  of  the  code  alone  nor  of  tbe  documentation  alone. 
Tbe  theme  is  that  in  order  to  provide  good  documentation 
from  the  user’s  point  of  view  it  is  necessary  to  identify  what 
information  the  user  needs,  and  when.  Then,  it  is  necessary 
to  provide  a  channel  from  the  situation  to  the  information. 
It  is  relatively  unimportant  what  media  are  used  for  this  in 
any  given  case:  they  could  be  messages  generated  by  the  sys¬ 
tem  or  notices  stuck  to  the  terminal.  What  matters  it 
whether  the  user  is  able  to  get  the  information  that  is 
required.  Note  that  it  is  not  relevant  that  the  information 
is  available  in  principle.  What  matters  it  whether  real  users, 
in  real  situations,  can  get  the  answers.  If  the  user  cannot 
solve  the  problem,  then  it  is  the  system  design  that  is  at 
fault,  whether  or  not  the  designer  can  demonstrate  that  the 
relevant  information  was  available  to  the  user:  the  critical 
test  is  the  practical  one— do  real  users  succeed  at  the  task? 

Debugging  the  Interface 

When  a  piece  of  software  has  been  implemented  it 
needs  to  be  tested  and  debugged:  the  same  applies  to  tbe 
user  interface.  In  the  past,  debugging  the  interface  has  gen¬ 
erally  been  left  to  the  customer,  whose  complaints  are  claaai- 
tied  aa  changes  to  the  specifications.  The  net  effect  tends 
to  be  that  changes  are  slow,  expensive,  resented  by  the  pro¬ 
gramming  team,  and  do  not  benefit  from  any  kind  of  sys¬ 
tematic  or  professional  approach.  Clearly  the  field  is  more 
than  ready  for  improved  practices. 

What  It  a  Bug? 

The  field  of  debugging  involves  many  issue*.  One 
oroblem  is  to  detetmine  what  counts  as  a  bug,  another  it  to 
determine  what  symptoms  can  be  detected  in  practice  (and 
what  proportion  of  bugs  escape  because  they  produce  no 
clear  symptoms),  and  yet  another  to  determine  tbe  cause 
from  tbe  symptom.  The  concept  of  'bug'  it  dcatiy  useful  in 
both  traditional  and  interface  software  engineering,  but 
nevertheless  it  has  no  clear  definition.  Some  bugs  are 
clear— if  an  explicit  specification  is  not  met,  tb*  implemen¬ 
tation  has  a  bug.  However  there  can  be  bugs  in  the  specifi¬ 
cation*  themselves,  and  hup  relative  to  implicit  specifica¬ 
tion*.  A  crucial  part  of  developing  interface  engineering 
will  be  developing  standards  that  become  implicit  specifica¬ 
tion*  for  all  interface  programming.  (The  analogous  points 
for  hep  in  programs  arc  discussed  in  Johnson,  Draper,  St 
Soloway1*.) 


Software  Engineering  for  User  Interfaces 

We  believe  that  tbe  system  specifications  should 
include  a  statement  about  the  clam  of  user  and  tbe  kind  of 
training  that  is  to  be  expected.  Tbe  system  should  then  be 
evaluated  with  that  very  same  class  of  user,  with  the  tame 
training  procedure.  If  tbe  user  then  has  problems,  there  is  a 
bug  in  the  system.  Tbe  bug  could  be  in  the  training,  or  in 
tbe  interface.  Tbe  point  it  tbat  we  cannot  determine  Just 
where  tbe  problem  ties  until  we  have  explicit  specifications 
for  all  aspect!  of  tbe  computer  system,  including  the  inter¬ 
face  and  the  user  performance.  When  we  have  specifica¬ 
tions  tbat  cover  the  user,  then  we  can  determine  how  rea¬ 
sonable  they  are  on  the  basis  of  tbe  user’s  abilities.  Only 
when  we  hnve  determined  that  tbe  specifications  are  indeed 
reasonable  can  we  then  claim  tbat  the  system  that  fails  to 
meet  thoie  specifications  is  at  fault.  Tbis  lesson  applies  to 
all  pans  of  the  system,  of  course,  but  its  implications  for 
assessing  tbe  role  of  tbe  user  as  a  pan  of  the  overall  system 
operation  seem  not  to  he  properly  recognized. 

Finding  Bugs 

The  only  way  to  And  hup  is  to  test.  Tbis  means  that 
the  system  must  be  put  through  its  paces  with  tbe  human 
user,  much  as  programs  are  put  through  their  paces  with 
test  sets  of  data.  Just  as  a  program  needs  testing  by  data 
tbat  exercise  every  branch  of  the  code,  to  tbe  user-program 
interaction  needs  testing  by  exercising  each  possible 
'branch'  of  the  interaction.  Unfortunately,  test  procedures 
for  user  interfaces  do  not  oast. 

Note  that  the  testing  phase  is  not  apt  to  be  easy.  It 
requires  tbe  development  of  good  test  problems,  of  a  good 
pool  of  users  upon  whom  tbe  tests  will  be  tun,  and  careful 
observation  and  evaluation  of  the  result.  It  is  critical  tbat 
tbe  users  upon  whom  tbe  system  be  tested  reflect  tbe  actual 
user  population  for  whom  tbe  system  is  designed.  Psychol¬ 
ogy  has  amsmad  a  number  of  methodological  tools  that  can 
be  of  use.  Other  tools,  specialized  for  tbit  particular  prob¬ 
lem,  need  to  be  developed. 

Leaning  bow  to  aak  users  for  information  is  as  big  a 
topic  a*  learning  bow  to  extract  useful  measurements  from 
computers.  For  instance,  consider  a  faulty  error  message. 
If  it  is  so  useless  tbat  tbe  user  cannot  understand  it  and  gets 
stuck,  then  is  often  a  bias  against  reporting  tbe  consequent 
failuta  to  carry  out  tbe  task  successfully  because  the  users 
are  apt  to  feel  tbat  tbe  problems  are  due  to  tbeir  own  inade¬ 
quacies.  On  tbe  other  band,  if  tbe  message  is  wrong  or  silly 
in  some  way  but  nevertheless  tbe  users  succeed  in  diagnosing 
the  real  problem  fairly  quickly,  then  they  are  likely  to 
express  their  irritation.  Note  that  this  means  tbat  the  non- 
fatal  Inadequacy  is  likely  to  receive  a  much  higher  rate  of 
spontaneous  complaints  than  tbe  much  more  serious  case 
which  causes  users  to  fail  completely.  Obviously  we  need  to 
lean  bow  to  work  around  phenomena  like  this.  For 
instance,  using  exhaustive  checklists  in  questionnaires’9 
ensures  tbat  one  solicits  opinions  on  alt  parts  of  an  inter¬ 
face,  and,  to  tome  extent,  allows  one  to  tee  things  such  aa 
matt  avoidance  of  a  command  tbat  no-one  complains  about 
spontaneously . 
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People  an  wary  sensitive  (o  the  context  in  which  they 
an  operating,  and  if  one  is  aot  careful,  the  test  population 
may  feel  that  it  it  they  who  are  being  evaluated  (rather  than 
the  system),  and  they  may  carefully  monitor  their  responses 
and  behavior  to  that  they  will  not  'look  bad*  or  'stupid'*. 
One  of  us  experienced  the  situation  where  a  deficiency  in 
the  system  was  not  reported  by  any  of  the  users  because 
they  attributed  the  difficulty  to  their  own  inadequacies,  not 
realising  that  it  could  be  avoided  by  a  (rather  simple)  design 
change.  In  this  cate,  it  required  an  experienced  observer  to 
watch  users  and  note  the  problem.  Note  also  that  the 
existence  of  any  problem  was  at  first  denied  by  the  design 
team  who  asked  "but  why  has  nobody  ever  complained?* 
This  sounds  reasonable,  but  is  analogous  to  a  programmer 
who  does  no  systematic  teats  and  then  uses  the  length  of 
time  before  the  first  complaint  as  evidence  that  complaints 
must  be  ill-founded.  This  is  nor  a  trivial  instance:  users 
who  feel  that  a  system  reveals  their  inadequacies  wiU  not 
wish  to  use  the  system  and  will  resist  its  introduction  into 
the  workplace.  Thus,  the  system  will  not  gut  usad  (or 
morale  may  suffer).  The  problem  is  to  devise  techniques 
that  allow  the  designer  to  revise  the  nature  of  the  diffi¬ 
culty.  It  will  take  extreme  sensitivity  on  the  part  of  the  tee¬ 
ter  to  overcome  these  problems.  It  is  here  that  the  skills  of 
the  experimental  psychologist  am  probably  essential. 

Debugging  Tools 

The  use  of  questionnaires  is  analogous  to  a  post¬ 
mortem  in  that  they  are  applied  Miter  the  program  has  run. 
One  of  the  most  prosing  needs  for  interface  debugging  is  to 
have  facilities  analogous  to  run-rime  rest*  built  into  all  com¬ 
puting  environments  that  cause  program  exceptions  for  bad 
addresses,  floating  point  overflow,  etc.  Although  an  impor¬ 
tant  function  for  these  is.  of  course,  the  protection  of  ocher 
users,  tbey  are  alto  valuable  for  debugging  becausu  they  stop 
execution  at  the  earliest  sign  of  trouble  and  give  the  pro¬ 
grammer  a  chance  to  gather  information  on  the  state  of  the 
process  at  that  point.  Ease  of  debugging  it  crucially 
affected  by  the  immediacy  of  error  detection,  as  anyone 
knows  who  has  debugged  programs  srith  and  without  array 
bounds  cbeckiog.  Applied  to  interface  debugging,  this 
means  developing  suitable  error  criteria,  and  then  acting  on 
it.  It  is  not  necessarily  appropriate  to  halt  e  program  when 
an  error  in  interface  interaction  is  detected,  but  at  the  least, 
one  could  create  a  relevant  'dump* — a  trace  of  the  whole 
interaction  together  with  as  much  information  as  possible 
on  the  users,  'heir  experience,  end  their  current  goals  and 
thoughts  at  the  time  of  the  difficulty 

The  various  existing  tuchniques  for  getting  at  the 
interaction  between  the  user  and  the  system  differ  in  their 
immediacy  and  the  information  provided.  Furthest  removed 
from  the  actual  interaction  is  the  collection  of  opinions 
after  tome  amount  of  experience  with  the  system  (e.g.,  it 
completion  of  the  training  period).  Closer  to  the  actual 
usage  it  the  use  o'  on-line  complaint  facilities.  A  still  more 
imaaediate  record  is  provided  by  history  traces  or  dribble 
files  that  provide  a  detailed  record  of  the  low -level  actions 
of  the  user,  but  without  any  of  the  goals  or  intentions. 


Intentions  and  goals  can  be  gotten  by  the  collection  of  real¬ 
time,  thinking-aioud  protocols  from  users  while  they 
interact  with  the  syttem.  Each  technique  offers  a  different 
perspective  on  the  interaction. 

Testing  the  Interface 

Improving  Measures  of  Performance 

la  addition  to  debugging,  a  programmer  will  typically 
be  concerned  with  examining  and  optimizing  certain  mcas- 
urea.  The  beat  parallel  here  is  with  the  problem  of  improv¬ 
ing  a  program’s  speed  of  execution.  The  conventional  wis¬ 
dom  on  the  timing  problem  is  that  a  typical  program  spends 
90%  of  its  time  in  10%  of  its  code,  so  the  strategy  is  to 
identify  that  10%  and  work  on  tuning  it,  since  work  on 
improving  the  other  90%  will  show  little  effect  overall. 
Thus,  profiling  tools  that  show  where  a  program  spends  its 
time  arc  important.  In  improving  an  interface,  several  issues 
ere  relevant:  how  many  users  find  a  given  command  prob¬ 
lematic?,  how  problematic  do  tbey  find  it?,  bow  often  does 
the  issue  arise?  As  with  debugging,  we  see  here  a  gap 
between  what  can  be  easily  and  directly  measured  and  the 
underlying  concern  of  the  designer. 

Like  profiling  tools,  then,  interface  tools  should  pro¬ 
duce  meesutes  of  those  things  that  can  be  used  by  the 
designer  to  pick  the  next  point  of  attack,  together  with  a 
measure  of  how  important  It  is  to  do  any  further  improve¬ 
ments.  Also  like  profiling  tools,  there  will  be  issues  of  bow 
accurate  these  measurements  are  (resolution  difficulties)  and 
how  representative  of  the  real  situation.  Ultimately  a  lot 
will  also  depend  on  the  experience  and  judgment  of  the 
designer  using  the  tool.  Thus  not  only  do  the  tools  need  to 
be  developed,  but  it  will  then  take  a  further  significant 
amount  of  time  to  accumulate  experience  in  the  use  of  these 

Another  tool  is  on-line  command  usage  measurements. 
It  is  relatively  easy  to  collect  a  running  record  of  command 
use  for  the  various  users  of  a  system,  thus  providing  reliable 
measures  of  how  often  commands  are  used,  and  by  what 
percentage  of  users.  The  frequency  of  use  is  important  in 
weighing  the  priority  to  be  given  to  problems.** 

Benchmarks  and  Acceptance  Tests 

Earlier,  we  discussed  Scbneiderman’s21  suggestion  that 
the  specification  of  the  interface  be  given  in  terms  of  tbe 
acceptance  teats  to  which  it  will  be  subjected.  This  idea  can 
have  far-reaching  effect  in  focusing  designers’  attention  on  a 
definite  goal  for  tbe  interface.  Whether  or  not  success  at  a 
particular  test  turns  out  to  be  a  good  guide  to  the  user’s 
long-term  satisfaction  with  tbe  product,  it  is  at  least  at  an 
appropriate  level  of  specification;  this  is  a  crucial  step  iu 

tt  Than  it  a  aujsr  problem  of  rmmUoa  of  privacy.  It  if  aot  appropri¬ 
ate  to  keep  record  oa  the  detail!  of  tadMdva!  Mart'  interactions 
with  a  qratem.  Oar  aolatiea  if  to  aecoda  tfco  aaar'a  idcatity  ao  that 
ahheagh  tbt  aaar  idaetity  caaaot  be  determined,  am  caa  Mill  match 
ap  the  particelar  coamaad  cequcneec  and  pro  pan  acafoa  with  tha 
aaar  coda.  This  it  aaacatial  la  allowing  tha  d  tic  ovary  of  coramoa 
patient  of  openlioe. 
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Software  EttguMaiag  for  Uaet  Interface* 


aoftware  engineering  to  interface  design. 

User-interface  benchmarks  will  be  most  dearly  useful 
when  tbe  aspects  of  performance  and  the  situation  in  which 
it  is  to  be  measured  are  dearly  defined.  As  a  general 
method  by  which  to  judge  a  whole  system,  benchmarks  are 
obviously  limited;  systems  differ  on  many  dimensions  and 
benchmarks  often  generate  only  a  single  measure.  The  use 
of  benchmarks  for  interfaces  is  further  problematic  in  these 
early  days  since  we  do  not  yet  know  all  tbe  crucial  variables. 
For  instance,  discussions  about  which  of  two  operating  sys¬ 
tems  are  more  effective  for  a  class  of  users  are  sometimes 
carried  on  without  considering  tbe  communication  rate  of 
the  chaand  to  tbe  user,  yet  this  crucially  affects  how  much 
feedback  is  perceived  as  a  painfully  time-wasting  nuisance. 
In  general,  factors  not  directly  under  the  control  of  the 
engineer  may  have  a  dominating  effect.  Until  we  are  more 
confident  of  being  conscious  of  the  factors  that  have  a 
major  influence  on  the  measures  we  arc  interested  in,  we 
will  not  know  how  to  run  benchmarks  in  which  they  are 
held  constant.*** 
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